During the past years, the access to Internet has made more and more people to use their computer or mobile phone or other device (user device) to download content, services, etc. from various service providers in order to watch movies, listen to songs, read the news, etc. Thus, content distribution networks (CDNs) have become common in the current Internet landscape. The CDNs provide mechanisms and network infrastructure that enable the service providers to improve the accessibility of the content to clients. FIG. 1 illustrates a system 10 having a client device 20 that connects to the service provider 30 to request content from the CDN 40.
Content may include web pages (and/or individual objects like images on web pages), video files and audio files. The clients may be persons surfing the web using a web browser or any other suitable application, e.g., a video streaming client. Improved accessibility in this context refers to lower delay, higher bandwidth and/or higher availability of the content, i.e., a reduction of the fraction of time during which the content is not available. A suitable source of content for the client device may be defined by a combination of these factors. Some known providers of CDN services at the time of filing this application are Akamai (see for example www.akamai.com) and Limelight (see www.limelight.com). Amazon has recently also entered into this market as part of their Web Services suite.
One feature of a CDN is to cache the required content close to the client, thereby reducing the time the client needs to fetch that content. For example, still with regard to FIG. 1, the CDN 40 may cache the content at cache 42. Another possibility is to provide another cache 44 closer to the client device 20. As the internet protocol (IP) is the networking protocol of the Internet and thus the one by which computers are globally interconnected, closeness may be defined in terms of IP router hops. Alternatively, the closeness may be defined based on a multitude of factors, one of which being measured in terms of the IP router hops. Another factor may be, for example, the cost of transporting bits across a certain link. Thus, all these factors may be considered into closeness metric. Hence, achieving closeness may translate into reducing the number of router hops from client to where the content is held.
While the simplicity of FIG. 1 suggests that the solution to the closeness problem is to place cache 44 closest to the client device 20, a more realistic situation may be as shown in FIG. 2, in which the client device 20 is roaming in Net A 32, which is a first service provider, but belongs to Net B 34, which is a second service provider. When the client device 20 requests certain content from the CDN 40, because the client device 20 belongs to Net B 34, a gateway node 35 of Net B 34 directs the request message to the CDN 40. The logic of the CDN 40 decides that the required content is to be found in cache 44 instead of cache 42 (i.e., the logic redirects the client device to cache 44 that is closer to the client device) and informs accordingly the gateway node 35. Next, the gateway node 35 transmits the position of the cache 44 to the client device 20 via Net A 32. Net A 32 includes a serving node 36 connected to a cache 46. Thus, the client device 20 will receive the desired content from cache 44, which in this situation is not the closest to the client device 20. The reason why the client device 20 downloads the content from cache 44 is discussed next.
FIG. 3 illustrates in more details the redirection functionality at the CDN 40 and the messages exchanged among the client device 20, the serving node 36, the gateway node 35, and the CDN 40. The client device 20 sends in step 1a request for location content. As the client device 20 is roaming in Net A 32, the serving node 36 forwards the request in step 2 to the gateway node 35, to which the client device 20 belongs. The gateway node 35 contacts the CDN 40 in step 3 to request the location of the desired content. The CDN 40 determines in step 4 the location of the desired content and informs in step 5 the gateway node 35 about the location of the desired content.
To determine the location of the desired content in step 4, the CDN 40 uses the IP address of the client device 20. More specifically, the CDN 40 applies some logic to the IP address of the client device 20 that takes into account where the CDN 40 has the requested content cached (cache 44 for example), and then the CDN 40 redirects the client device 20 to the best located cache with respect to the position of the client device 20.
This decision is thus largely affected by the IP address of the client device 20. The IP address of the client device 20 is extracted by the CDN 40 from the IP header of the request sent in step 1 by the client device 20. This approach works well if that IP address reflects the client device's true location in the IP domain. However, if the true location of the client in the IP domain is not accurately reflected in the IP address of the client device 20, this approach fails and the CDN 40 may not determine the closest cache to the client device 20.
One example in which the true location of the client device in the IP domain is not reflected in the IP address of the client device 20 is when there are IP tunnels involved so that the connectivity of the client device is somewhere tunneled. In this situation the client device 20 appears to be at one location but is in reality somewhere else. As a result, the cache 44 determined by the CDN 40 will be suboptimal and the benefits of the CDN 40 logic will be compromised.
An example of such a situation is when the client device obtains the connectivity from a 3rd Generation Partnership Project (3GPP) mobile network. The architecture of 3GPP mobile networks is built around tunneling since the IP level mobility solution is GPRS Tunneling Protocol (GTP), the General Packet Radio Service (GPRS) tunneling protocol. In this network, the client is given an IP address that does not change and is topologically anchored in the gateway node 35, regardless of where the client device actually is located in the IP domain, i.e., regardless that the client device 20 is active inside Net A 32 and served by the serving node 36. Other networks that do not use the 3GPP architecture may also use an IP address for a client device that is not indicative of the real geographical location of the client device.
Returning now to FIG. 3, the CDN 40 having performed an inaccurate determination in step 4 of the closest cache 44 to the client device 20 (because of the IP problems discussed above), provides the inaccurate location to the gateway node 35 in step 5. The gateway node 35 transmits this location in step 6 to the serving node 36, which also transmits the location to the client device 20 in step 7. Having the location of the content, the client device 20 requests the desired content in step 8. The serving node 36 forwards the request in step 9 to the gateway node 35. The gateway node 35 downloads in step 10 the content from cache 44 and sends the content in step 11 to the serving node 36. The serving node 36 transmits that content in step 12 to the client device 20.
This example shows that those networks that use an IP address of the client device that does not correspond to the geographical position of the client device may not provide the closest cache to the client device as the cache 44 has been used instead of cache 46, which is closer than cache 44.
In the example discussed with regard to FIGS. 2 and 3, the CDN 40 included a Hypertext Transfer Protocol (HTTP) based redirection mechanism for determining that cache 44 is closer to the client device than cache 42. However, other protocols may be used in conjunction with the redirection mechanism. For example, FIG. 4 shows a system 12, similar to system 10 of FIG. 2, but with the difference that a domain name system (DNS) redirection mechanism is used by the CDN. The messages exchanged between the client device 20, the serving node 36, the gateway node 35 and the CDN DNS 41 are illustrated in FIG. 5. This oversimplified figure indicates that the client device 20 sends a message in step 1 for performing a DNS lookup for the address of a cache having the desired content. The CDN DNS 41 responds in step 2 with the address of the cache 44 having the desired content. Based on this information, the client device 20 sends in step 3 an HTTP “GET CONTENT” command to obtain the desired content and in step 4 receives the desired content.
In both examples illustrated in FIGS. 3 and 5 the redirection mechanism is located in the CDN 40 (either HTTP based or DNS based) and the IP address, of the client device 20, received by the CDN 40 does not correlate with the geographical location of the client device 20. For this reason, the CDN 40 fails to correctly inform the client device 20 about a cache 46 that is closer to the client device 20 than the determined cache 44.
Accordingly, it would be desirable to provide devices, systems and methods that avoid the afore-described problems and drawbacks.